การตรวจสอบรายละเอียดเกี่ยวกับ Metric ของ Mackerel

บทความนี้ผมได้แปลมาจากบทความที่เป็นภาษาญี่ปุ่นที่ชื่อว่า Mackerelのメトリックについて詳しく見てみた
เจ้าของบทความนี้ก็คือ คุณ きだぱん หรือ คิดาปัง เป็นคนญี่ปุ่นครับ

เนื่องจากว่าบทความนี้แปลมาจากภาษาญี่ปุ่น เมื่อแปลมาเป็นภาษาไทยแล้วผมได้เรียบเรียงเนื้อหาใหม่เพื่อให้เข้าใจง่ายขึ้น ! เมื่อพร้อมแล้วเราไปดูรายละเอียดเกี่ยวกับ Metric กันเลยครับ

สำหรับผู้ใช้งานที่ต้องการรู้เกี่ยวกับ Mackerel เพิ่มเติม สามารถอ่านที่บทความต่อไปนี้ได้เลยครับ

---

สวัสดีครับ ผม คิดาปัง ครับ

ทุกคน Monitoring กันอยู่ไหมครับ?

ครั้งนี้คือบทความเกี่ยวกับ Mackerel และ Solution การ monitoring ของ SaaS
ในการใช้งาน Mackerel ผมคิดว่าค่าของ Metric คือ จุดที่ควรให้ความสำคัญในเรื่องของการรับข้อมูล Server resources เช่น อัตราส่วนการใช้ CPU และ Memory จะทำให้สามารถตรวจสอบเชิงปริมาณได้ว่ามีการใช้งานไปมากน้อยเพียงใด ซึ่งเป็นตัวชี้วัดสำหรับการตัดสินใจในการระบุสาเหตุและรับมือเมื่อเกิดปัญหานั่นเอง
ครั้งนี้ผมเลยต้องการที่จะมาเขียนบทความโดยเน้นไปที่ Metric System ที่ถูก Post โดยฟังก์ชันมาตรฐานของmackerel-agentกับ Metric ที่ใช้งานได้ใน Mackerel

ถ้าพร้อมแล้ว ไปดูกันเลยครับ ! !

ประเภท Metric

Metric ที่ใช้งานได้ใน Mackerel มีอยู่ 2 ประเภทหลักๆคือ Host metric และ Service metric ครับ

Host metric

• Metric ที่เกี่ยวกับ Host เช่น อัตราการใช้ CPU และปริมาณการใช้ Memory
• Metric ที่เชื่อมโยงกับ Host ที่เป็นเป้าหมายการตรวจสอบ
• ใน Host metric จะถูกแบ่งเป็น System Metric และ Custom Metric

Service metric

• Metric ไม่ได้ขึ้นอยู่กับ Service ที่เฉพาะเจาะจง
• สามารถ Post metric ได้อย่างอิสระจาก API
• ตัวอย่างเช่น
  • การเปลี่ยนแปลงของจำนวน User ทั้งหมดที่ได้ลงทะเบียนใน Service
  • การเปลี่ยนแปลงของจำนวน PV ในเว็บไซต์
  • KPI ที่เกี่ยวกับธุรกิจ เช่น จำนวนคำสั่งซื้อ หรือ ยอดขายที่ได้รับจากเว็บไซต์ EC

POST Service metric มีการอธิบายรายละเอียดไว้ที่นี่

ครั้งนี้ผมจะมาอธิบายเกี่ยวกับ System metric ที่ถูก Post โดยฟังก์ชันมาตรฐานของmackerel-agent

System metric

System metric ถูก Post โดยฟังก์ชันมาตรฐานของmackerel-agentที่ติดตั้งบน Host และแสดงกราฟทั้ง 6 แบบคือloadavg,cpu,memory,disk,interface,filesystem

มาดูเกี่ยวกับวิธีการสังเกตและวิธีการคิดค่าของ 6 แบบนี้กันครับ

loadavg

loadavg คือค่าเฉลี่ย load ซึ่งเป็นจำนวนของ process ที่รอดำเนินการและเป็นค่าผลรวมจำนวน process ของค่า I/O ใน disk
ในกรณีที่ใช้ mackerel-agent แหล่งที่มาของ Metric จะได้รับโดยผ่านการวิเคราะห์เนื้อหาของ/proc/loadavg
นอกจากนี้ยังสามารถตรวจสอบด้วยคำสั่งuptimeหรือwที่เป็นคำสั่ง Linux ได้อีกด้วย

# uptime
 00:45:35 up 19:18,  1 user,  load average: 0.00, 0.01, 0.05
# w
 00:11:27 up 20:16,  1 user,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
*****   pts/0    **.**.**.**.*     00:45    5.00s  0.00s  0.00s w

ดูที่ค่านี้ซึ่งเป็นส่วนที่สำคัญ เพราะว่าถูกใช้สำหรับแสดงสถานะการใช้งานของระบบทั้งหมด ซึ่งค่าอาจจะมีการเพิ่มขึ้นโดยรวบรวมการประมวลผลอย่างรวดเร็วในระยะเวลาที่กำหนดไว้ตามลักษณะของระบบ ในกรณีนี้ไม่ควรมองว่าเป็นปัญหาในทันทีเพียงเพราะเห็นค่าเฉลี่ย load ที่เกิน
ในตอนที่ค่าในกราฟมีแนวโน้มที่จะเพิ่มขึ้นในทางขวาบนเรื่อยๆ หมายความว่า [จำนวนการประมวลผลที่จัดการจริง] ＜ [จำนวนการประมวลผลทั้งหมดที่ควรจัดการ] หากปล่อยไว้แบบนี้ process ที่รอดำเนินการจะสะสมเยอะขึ้นเรื่อยๆ แล้วจะส่งผลให้การประมวลผลช้าลงด้วย
นอกจากนี้เราไม่ควรตัดสินใจโดยดูแค่ค่าเฉลี่ย load Average เท่านั้น เพราะโดยปกติ CPU ของเซิร์ฟเวอร์จะทำงานหลาย Core ดังนั้นการดูที่จำนวน Load Average / Cores จะเข้าใจได้ง่ายกว่าการดูแค่ Load Average นั่นเอง

สามารถตรวจสอบใน mackerel-agent.conf ได้โดยการเพิ่ม Code นี้ !

[plugin.metrics.multicore]
command = "mackerel-plugin-multicore"

CPU

CPU จะแสดงอัตราการใช้งาน CPU ที่เป็นหน่วยประมวลผลการคำนวณต่างๆ
ในกรณีที่ใช้ mackerel-agent แหล่งที่มาของ metric จะได้รับโดยผ่านการวิเคราะห์เนื้อหาของ/proc/stat
CPU จะแตกต่างไปตามหน้าที่ของ server ทำให้ต้องปรับการตั้งค่าและขีดจำกัดในแต่ละ Role
นอกจากนี้ Mackerel สามารถตรวจสอบอัตราการใช้งานแยกตามประเภทต่างๆได้ และถ้าเป็นไปได้อยากให้คุณจำ 4 ข้อด้านล่างนี้ไว้ จะเป็นประโยชน์ต่อคุณ

• cpu.userอัตราส่วนของเวลาที่ใช้นอกเหนือจาก kernel
• cpu.iowaitอัตราส่วนของเวลาที่มีสถานะว่าง (idle) ที่เกิดจากการรอ I/O
• cpu.systemอัตราส่วนของเวลาที่ใช้ kernel
• cpu.idleอัตราส่วนของเวลาที่ CPU มีสถานะว่าง (idle) และไม่ต้องรอ I/O

memory

memory ตามชื่อเลยก็คือจะแสดงสถานะการใช้งาน memory
ในกรณีที่ใช้ mackerel-agent แหล่งที่มาของ metric จะได้รับโดยผ่านการวิเคราะห์เนื้อหาของ/proc/meminfoหลังจากที่ Mackerel ได้มีการเปลี่ยนแปลงวิธีการคำนวณอัตราการใช้งาน memory ในปี 2018 ก็ได้มีการปรับการคำนวณให้เป็นused + available = totalและนอกจาก used แล้วมีแค่ available ที่จะแสดงข้อมูลแบบเรียงซ้อนกันเท่านั้น รายละเอียดการใช้งาน memory ของ Linux ในปัจจุบันนี้มีความซับซ้อน เพราะ buffers และ cached ไม่จำเป็นต้องเป็นพื้นที่ว่างเสมอไป

disk

disk คือค่าการอ่านและการเขียนของ disk ที่เรียกว่า IOPS (การเข้าถึง I/O ต่อ 1 วินาที ) แหล่งที่มาของ metric จะได้รับโดยผ่านการวิเคราะห์เนื้อหาของ/proc/diskstatsและจะถูกเขียนค่าของdisk.*.reads.delta,disk.*.writes.delta
ในกรณีที่เป็น metric ที่น่าจับตามอง เช่น การอ่านและเขียนของ disk ที่มีความโดดเด่นในฐานข้อมูลและเซิร์ฟเวอร์จัดเก็บข้อมูล
ใน Linux สามารถตรวจสอบด้วยคำสั่งsar,iostat,vmstat -dได้
นอกจากนี้ยังสามารถดูรายละเอียดเพิ่มเติม โดยใช้คำสั่งcheck-diskที่เป็น Collection of official check plugins ได้

interface

interface คือสถานะการใช้รับส่งข้อมูลทางเครือข่าย (Network bandwidth) โดยมีหน่วยเป็น KB/วินาที, txเป็นการส่งข้อมูล, rx เป็นการรับข้อมูล
ซึ่งจะได้รับโดยผ่านการวิเคราะห์เนื้อหาของ/proc/net/dev
เนื่องจากว่าในสภาพแวดล้อม Cloud ส่วนใหญ่ มีค่าใช้จ่ายการสื่อสารของเครือข่าย โดยตั้งค่าการตรวจสอบจากมุมมองนี้ ซึ่งผมคิดว่าจะเชื่อมโยงไปสู่แนวทางปฏิบัติที่ดีที่สุด

filesystem

filesystem คือ metric ที่แสดงขนาดและปริมาณการใช้งานของ disk
โดยจะได้รับโดยผ่านการวิเคราะห์ผลการดำเนินการของคำสั่งdfในกรณีที่ตรวจสอบขนาดของ directory ตามด้านล่างนี้ ให้ใช้คำสั่งduบน Linux
Mackerel สามารถใช้ฟังก์ชันการถดถอยเชิงเส้นที่ว่าคือlinearRegression(),timeLeftForecast()สำหรับฟังก์ชันการคาดการณ์ในอนาคตได้ และสามารถตรวจสอบเวลาที่เหลืออยู่ได้จนกว่าพื้นที่ว่างบน disk ของระบบไฟล์ (System file) จะหมดไป

scale(timeLeftForecast(host(host_id, filesystem.drive.used), 3mo, 2000000000000), 1/86400)

ตัวอย่างเช่นสูตรข้างต้น คือค่าที่ถดถอยเชิงเส้นโดยใช้ค่าของ Host ที่ระบุ 3 เดือน โดยสามารถรับจำนวนวินาทีได้จนถึง 2000000000000byte(2TB) ได้

จนถึงตอนนี้ เราได้แนะนำเกี่ยวกับระบบ metric ไปแล้ว แต่ scource code ของ mackerel-agent มีการเผยแพร่ตามบทความด้านล่าง

สรุป

ในส่วนนี้คือการสรุปมุมมองเกี่ยวกับระบบ metric ของ Mackerel
ผมหวังว่าบทความนี้จะช่วยเป็นแนวทางเพื่อตัดสินใจในการระบุสาเหตุและรับมือเมื่อเกิดปัญหาด้วยความเข้าใจเหล่านี้
สิ่งที่ผมได้แนะนำในครั้งนี้เป็นฟังก์ชันมารตฐาน ดังนั้นลองไปทำการปรับแต่งและตรวจสอบในแต่ละฟังก์ชันกันดูนะครับ